Pinging @elastic/security-threat-hunting-investigations (Team:Threat Hunting:Investigations)

💚 Build Succeeded

• Buildkite Build
• Commit: 4a4add2

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

History

• 💔 Build #432542 failed f69b004
• 💛 Build #431674 was flaky a8260aa

Hey @PhilippeOberti, thanks for this wanted to clarify a workflow.

I have a related open PR (#267895) that enables the picker in EDITABLE mode specifically on Explore pages (Hosts, Users, Network, entity detail views), and DISABLED everywhere else.

Your approach is READ_ONLY across all Security Solution pages, which is broader. These two will conflict in plugin.tsx , whoever lands second overwrites the resolver.

A few questions :

• Is the intended end state READ_ONLY everywhere with Explore pages being EDITABLE on top? Or should non-Explore pages be DISABLED entirely?
• If we want both, should we layer them (your baseline + our override for Explore), or should one PR absorb the other?

cc @jaredburgett

Hey @PhilippeOberti, thanks for this wanted to clarify a workflow.

I have a related open PR (#267895) that enables the picker in EDITABLE mode specifically on Explore pages (Hosts, Users, Network, entity detail views), and DISABLED everywhere else.

Your approach is READ_ONLY across all Security Solution pages, which is broader. These two will conflict in plugin.tsx , whoever lands second overwrites the resolver.

A few questions :

• Is the intended end state READ_ONLY everywhere with Explore pages being EDITABLE on top? Or should non-Explore pages be DISABLED entirely?
• If we want both, should we layer them (your baseline + our override for Explore), or should one PR absorb the other?

cc @jaredburgett

@abhishekbhatia1710 how recent is your information? Over the last couple of weeks I've attended a few CPS related meetings and it was always mentioned that the goal is to have it READONLY on all Security pages.
The picker was disabled before, and my PR changes that to READONLY.

I have never heard that some pages would be EDITABLE.

If that's what we truly want, then for sure we need to ensure that by default all pages should be READONLY, and only override that to EDITABLE for some pages.

I'll check with product today and will report back (@paulewing)

Hey @PhilippeOberti, thanks for this wanted to clarify a workflow.
I have a related open PR (#267895) that enables the picker in EDITABLE mode specifically on Explore pages (Hosts, Users, Network, entity detail views), and DISABLED everywhere else.
Your approach is READ_ONLY across all Security Solution pages, which is broader. These two will conflict in plugin.tsx , whoever lands second overwrites the resolver.
A few questions :

• Is the intended end state READ_ONLY everywhere with Explore pages being EDITABLE on top? Or should non-Explore pages be DISABLED entirely?
• If we want both, should we layer them (your baseline + our override for Explore), or should one PR absorb the other?

cc @jaredburgett

@abhishekbhatia1710 how recent is your information? Over the last couple of weeks I've attended a few CPS related meetings and it was always mentioned that the goal is to have it READONLY on all Security pages. The picker was disabled before, and my PR changes that to READONLY.

I have never heard that some pages would be EDITABLE.

If that's what we truly want, then for sure we need to ensure that by default all pages should be READONLY, and only override that to EDITABLE for some pages.

I'll check with product today and will report back (@paulewing)

Thanks for the context @PhilippeOberti ,I have only recently been introduced to the CPS space and wasn't part of those meetings, so I wasn't aware that READ_ONLY was the consensus for all Security Solution pages. Good to know! Thanks for your clarifying inputs.

@PhilippeOberti not sure if the attached screenshot is up to date.

But when in READ-ONLY, I find the text: You can adjust it for your space, or override it for individual queries inaccurate.

As far as I know, we don't allow in the security solution to override it for individual queries.

Thanks for the review @kfirpeled. We don't own nor control what's shown in the picker itself. We can just drive its state, so I'm not sure about it's content...
I'm reaching out to platform to get some clarity on their intentions behind this message.

If I had to guess, it was meant for things like ESQL in Discover or Timeline, where a user can indeed override for a specific query.

I tested it out and the readonly popover works as expected. I notice the Revert to space default button doesn't do anything. Is that expected? Should that be disabled as well if it doesn't do anything?

Thanks for the review @ashokaditya . We don't own nor control what's shown in the picker itself. We can just drive its state, so I'm not sure about it's content...
I'm reaching out to platform to get some clarity on their intentions behind the button. It does feel a bit odd indeed...

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: 3bb4145
• Build duration: 74 mins

Failed CI Steps

• FTR Configs #13
• FTR Configs #14

Test Failures

• [job] [logs] FTR Configs #14 / Cloud Security Posture - Group 5 (KSPM + Flyouts) Security Alerts Page - Graph visualization expanded flyout - filter by node
• [job] [logs] FTR Configs #13 / discover/esql_4 discover esql controls when adding an ES|QL panel with controls in Dashboard and exploring it in Discover should retain the controls and their state

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

History

• 💔 Build #449818 failed 76a1057
• 💛 Build #444741 was flaky 0093c52
• 💔 Build #441564 failed 999f137
• 💚 Build #436973 succeeded f64331b
• 💛 Build #435692 was flaky 7ac7e80